BBS in a Box 7

home *** CD-ROM | disk | FTP | other *** search

/ BBS in a Box 7 / BBS in a Box - Macintosh - Volume VII (BBS in a Box) (January 1993).iso / Files / Prog / D-G / Demo of Resorcerer 1.1.1.cpt / Resorcerer 1.1 Read Me Files / Resorcerer Scripts 1.1 < prev

Wrap

Text File | 1992-04-11 | 32KB | 442 lines

Resorcerer® Scripts Version 1.1 Spring, 1992 ================== Resorcerer 1.1 has a new scripting mechanism that makes it easier to do complicated resource file builds. These scripts implement a small subset of Apple’s Rez™ language, with some enhancements and cleanup, and they do so in conjunction with Resorcerer’s other interactive editing mechanisms. Please note that Resorcerer’s scripting mechanism is *not* a full blown resource compiler like Rez/SARez. However, it does have enough capabilities to do useful resource file management sorts of things, and (of course) Resorcerer is itself now being built with the aid of its own scripting mechanism, which only guarantees that it will get better. For instance, managing the building of both the Demo version and the Shipping version of Resorcerer is now a lot easier to do conditionally from one script file. The following describes the current state of affairs as of the above version. There are only an infinite number of features to add to the soup after these. Opening Script Files ================== A Resorcerer script is a file of type ‘TEXT’ whose name ends in the current script suffix. When Resorcerer is shipped, this suffix is set to a default of “.rc”. The default script suffix is set to “.rc” rather than “.r” to help distinguish Resorcerer scripts from Rez source files. However, you can change the suffix to anything you want, including “.r” if you want to design a script to be both. To set the default script file suffix, use the File Preferences section of Resorcerer’s Preferences... command in the Edit menu, where a new edit field lets you set the suffix string. The script is kept as a stream of standard printable Macintosh ASCII text in the text file’s data fork, and you can create the script using your favorite source code editor. Resorcerer 1.1’s new Open File... command now lets you choose from a variety a file types using a popup menu below the files/folders list. The last entry in this popup sets the list to show you only script text files, as defined by the current script suffix. When this type of file filtering is on, opening a script is a request to Resorcerer to *run* the script rather than to edit any resources that might be in the script file’s resource fork. If you need to *edit* actual resources in the script file’s resource fork, you must choose one of the other file filtering modes to open and get at the file’s resources. There is no extra menu command in Resorcerer’s File menu for directly opening a script. You have to choose Open File... and set the subsequent popup to show scripts only. The popup menu remembers its state from the last time you opened a file, however, so you don't need to do anything for subsequent script opens. There is a command key shortkut, CMD-K (Kompile Script), not attached to any menu item, that sets the subsequent Open File... dialog to display scripts-to-be-run only. In addition, when the Open File... dialog is showing, the two command keys, CMD-O and CMD-K, let you set the popup menu’s file filtering mode. CMD-O sets the popup to “Show All Files”, and CMD-K sets it to “‘.rc’ scripts only”. The popup ‘MENU’ resource has CMD-O set initially to “Show All Files”. Whichever of the various resource file editing filters in the menu has CMD-O attached to it is taken as the type of filtering to use the first time you run Resorcerer. If you want to set the default to something else, like “‘.rsrc’ only”, change the CMD-O in the menu to that command. You can include script files in your list of favorite files attached to the “Quick Open” sub-menu just like other files. When you edit the Favorite Files list in the Preferences dialog, the state of the “Scripts Only” filter is kept with the file entry. You must set the popup to filter scripts first before clicking the Add button. Otherwise the script file will be quick-opened as a normal resource file would instead of being run. In the unlikely event that there is a conflict, just delete the file from the list and add it again using your preferred filter setting. Running Script Files ================== Running a script causes Resorcerer to create a hidden, in-memory new resource file, called the working file, whose name is the same as the script file’s, with the exception that the current script suffix is replaced with the current default resource file suffix. For the standard defaults, this means that, for example, running the script “Foobar.rc” will cause Resorcerer to create the (hidden) working file, “Foobar.rsrc”. The Finder type and creator codes automatically default to the same as those Resorcerer uses for other new resource files. If, during interpretation, the script explicitly specifies an output file name, then Resorcerer renames the working file to the new output name, and will eventually save the working file to disk when the script finishes successfully. Otherwise (that is, if the script does not specify an output file) the working file maintains its default name but is simply *opened* as a new file for interactive editing when the script ends. This means that the completely empty script file (one with no commands in it at all) opens a new empty resource file for editing. In both cases, the file is marked dirty so that it will be saved to disk when it is closed. This behavior may change in the future with the introduction of an explicit “new <filename>” type statement, in which case the empty script will do nothing. If the script has caused resources to be added to the working file (which is the primary purpose of script files at this time), the added resources are not marked dirty, even though the resources are logically new. This lets you continue to use the resource dirty-bit mark to indicate “resources you have changed since the file became interactively editable” in case the script makes the file interactively editable before saving. [For those of you interface designers, this is a classic example of the difference between visual logic and programmer logic in the service of a better user interface]. If, during the execution of the script, an error occurs (usually a syntax error, a file-not-openable error, or an out-of-memory error), the error is reported, execution of the rest of the script is aborted, the working file in its current state is made interactively editable, and an attempt is made to close it, which you can confirm or not, depending on whether or not you want to check anything or otherwise muck about in the new file. Because of #include files, it is not difficult (if not impossible) to know beforehand how long a given script is going to take to execute. Resorcerer puts up a progress dialog to indicate what it is up to as it executes the script. When resources are included from other files, execution slows down quite a bit due to the Resource Manager’s disk accesses, but it is possible to tell beforehand how much work is about to be performed, so in these cases a progress bar is updated in order to keep you from going to sleep. If you are having a nightmare anyway, you can still hit CMD-period to abort the running script early. Script errors are reported in an alert. The general format of an error is to tell you what the problem was: what was expected and what was found. This message is usually followed by a token stack dump, telling you what line the problem was found on, and the context of the error. Given that Resorcerer does not have its own script text editor, this style of error reporting is pretty useful. Script File Preprocessor Syntax ============================ Like both Rez and C source files, Resorcerer scripts are composed of a simple C-like declarative language. In addition, there is a preprocessor for implementing symbolic macros and conditional interpretation. Preprocessor directives are currently a subset of the Rez and C preprocessor directives. The preprocessor supports the usual syntax of #<directive> <arg> that is, a pound sign ‘#’ followed by a directive word followed by any optional arguments. The ‘#’ must be the first non-white space character on a line. The preprocessor does *not* support any expression evaluation at this time. Its primary purpose is to be able to read reasonably simple C header files in which you keep only your symbolic resource ID definitions or enumerations. The following directives are currently supported: #include <filepathname> #define <macroname> <macrotext> #undefine <macroname> #undef <macroname> #ifdef <macroname> #ifndef <macroname> #else #endif In addition, there is a script statement for C-style “enum”s; “enums” are converted into sequential symbolic definitions of numbers in the preprocessor dictionary (see below). The details on the preprocessor capabilities are as follows: #include <filepathname> This suspends input from the current script text file, and begins reading input from the given file. The given file must have type ‘TEXT’ or an error occurs. The pathname must be contained in standard string (non-typographic) double quote marks, as in #include "::Headers:MyApplication.rc.h" Included text files can themselves contain nested #include directives, up to some maximum inclusion level. Unlike in THINK C, you have to be explicit about location of the target file with respect to the script file’s own folder. Resorcerer doesn’t search all subdirectories for the first name that matches. Under System 7, if the included <filepathname> is an alias file, then Resorcerer will resolve the alias and open the target file for inclusion. It only does this if the “Resolve alias files” setting is in effect, as shown by the popup in the Open File... dialog. The most common use for this directive is so that you can create a header file in which you keep symbolic definitions for the resource IDs that your application uses in calls to Get1Resource(). This ID definition file can then be used by your C compiler, Rez, or Resorcerer to specify resources by symbolic (i.e. semi-readable) name, rather than obscure number. #define <macroname> <macrotext> This enters <macroname> into the preprocessor’s dictionary of symbolic macro names with a definition of <macrotext>. <macroname> must start with an alphabetic character or an underscore, and can be composed of up to 255 alphanumeric/underscore characters. <macrotext> is everything past <macroname> up to the first un-escaped carriage return. During subsequent scanning of the input script text, any identifiers that match the defined <macroname> will have <macrotext> substituted for them on the input, whereupon the defining text is re-scanned with possible other substitutions. Currently, these macros cannot take parenthesized argument lists. Also, the case of the characters used in <macroname> is ignored. “OpenDialogID” and “opendialogid” are recognized as the same name. It is an error to attempt to define a name that is already defined in the dictionary. The most common use of the #define statement is to define names for the purposes of conditional operations, or to create symbolic names for resource IDs. A file containing nothing but resource ID definitions can then be included as a header for your application’s C compiler, Rez compiler, or Resorcerer script using the previously mentioned #include directive. #undefine <macroname> #undef <macroname> Either of these (they are synonyms) removes a previously defined <macroname> from the dictionary. It is an error for <macroname> not to be found in the dictionary. #ifdef <macroname> ... #else ... #endif This creates a conditional section of the script, which is scanned and either executed or ignored depending on whether the given <macroname> has been entered into the preprocessor’s dictionary or not. If it has, then script text up to the next matching #else or #endif is included. If not, then script text between the next matching #else and its matching #endif is included. #ifdef/#else/#endif directives can be nested up to some maximum level. The #else clause is optional. The most common use for these is so that you can write just one script file that conditionally does different things depending on a single defined name. This typically happens when you have more than one version of an application (e.g. a working and a demo version), where the two share the majority of your project’s resources, but there are still some minor differences in resources that both versions contain. For instance, Resorcerer’s Demo Version includes all the various TMPLs directly in its own resources; whereas the shipping version keeps them in their respective files. So our script for Resorcerer uses an #ifdef to optionally include them depending on whether a constant, DemoVersion is defined or not. #ifndef <macroname> ... #else ... #endif This is the same as as the #ifdef directive described above, except that the sense of the condition is reversed. Here script commands between the #ifndef and its #else is executed if <macroname> is not defined. The #else clause is optional. Script Syntax ============ Once the preprocessor has done its secret work of substituting definitions for names, Resorcerer scans the input for white-space-separated tokens. It also throws out all text in any comments. Comments have the form /* This begins a comment. In Resorcerer scripts, comments can nest, so that all of these following comments are processed correctly. /* This is a standard C- and Rez-style comment */ /• This is a Resorcerer-script-specific comment (bullets are Option-8) •/ • Everything to the end of this line is ignored // So is everything to the end of this line and we end our original comment here */ Tokens are of the form: <name> kFoobar _Undershirt_ AB4039 enum change <decimalnum> 128 -41 +7 <hexnum> 0xFFFF $80 <literal> 'C' 'DLOG' 'scod' 'Tab\t' '\0\0\0\0' <string> "abcdefghijklmnopqrstuvwxyzebraandbeyond" "Error\r" "" <character> = ( { , ; Currently, Resorcerer scripts have *no* expression evaluation capability, and Rez-style string variables are not yet supported. The syntax is entirely declarative, where declarations look like: <keyword> [ [ ( ] <arglist> [ ) ] ] [ [ { ] <subdeclarationlist> [ } ] ] [ ; ] and items in brackets are [sometimes] optional. <keyword>s are case-insensitive, and must be one of the currently defined (supported) keywords. The syntax for individual script keywords is described in the following paragraphs. Enumerated resource IDs ---------------------- enum { <name> [ = <number> ] , <name> [ = number ] , ... , <name> [ = <number> ] } ; This declares a C-style enumeration. Each symbolic <name> is defined in the preprocessor’s dictionary to a number (actually, a string of digits). If a <name> is followed by an optional “= <number>”, then the digits of <number> are used; otherwise, the number entered is 1 more than the previous number defined in this enum. If the first <name> doesn’t explicitly provide a <number> to start the enumeration count, then the count is started at 0. Enumerations are nice ways to create long lists of symbolic resource IDs while guaranteeing that each symbolic name has been defined to a unique ID, and they are used quite a bit in C program header files. “enum”s are most useful for multiple resources of the same type. This simply lets your script #include a wider variety of header files than it would be able to otherwise. An example of an enum declaration might be something like... enum { kProgressDialogID = 128, // start enumeration at 128 instead of the usual 0 kSearchDialogID, // implicitly defined as “129” kCompareDialogID = 140, // explicitly defined as “140” kPreferencesDialogID, // implicitly defined as “141” kSaveChangesID // implicitly defined as “142” }; Output File Specification ---------------------- create <filepathname> This declares the name, and whereabouts with respect to the current script file, of the current working file. If the script has no “create” command in it, the current working file will be opened for editing when the script finishes. This keyword has no immediate effect other than to internally rename the current working file, which Resorcerer creates in memory automatically when you first run any script, but which is not written to disk until later on in the script, usually when the script ends. This keyword is not Rez-compatible. Legal examples: create "New Demo.π.rsrc" Create "MyApplication.rsrc"; create("NoSuffix Resources") filetype ( <literal> ) creator ( <literal> ) The working file is given the same Finder signature type and creator codes that Resorcerer normally gives any new file (which are, respectively, type('RSRC') creator('Doug')). You can override either of these explicitly using the “filetype” or “creator” keywords. Legal examples: FileType('TEXT') Creator('G•D!') Resource Range Specifications --------------------------- Most of the commands that follow take as arguments either a single resource specification, <resource>; a resource range specification, <range>; or resource range list, <rangelist>. A single <resource> specification consists of a four-character literal resource type and a numeric resource ID. If you don’t care about the resource attribute bits or optional resource name, you can simply write the type and ID. If you want to specify a name or attributes, they, along with the ID, must be enclosed in parentheses. Note: Rez/SARez often requires the ID to be parenthesized even when the other optional stuff is not necessary, and may further require the ID, name, and attributes to occur in that order. IMPORTANT! Regardless of Resorcerer’s Preference setting for including related or owned resources in interactive selections, script files at this time only operate on explicitly described resources or ranges of resources. Legal single <resource> specifications include: 'DLOG' 128 'TEXT' (129,"Preamble") 'CODE' (2,preload,locked) 'STR#' (preload, 4, "Errors", purgeable) By default, the resource name is the empty string, and the attribute bits are set to all clear. The parenthesized list of items can contain, in any order, 1 resource ID number, 0 or 1 resource name strings in quotation marks, and any of the standard Rez-style attribute bit names: appheap sysheap nonpurgeable purgeable unlocked locked unprotected protected nonpreload preload A resource <range> consists of a resource type, optionally followed by an ID or ID range and/or other optional parenthesized info that defines which resources fit in the range. Examples of legal resource <range>s: 'STR#' • All resources of type 'STR#' 'STR#' 100:200 • All 'STR#'s with ID's in the range 100 to 200, inclusive 'STR#' () • All resources of type 'STR#' 'STR#' (128:32767) • All 'STR#'s with ID's greater than or equal to 128 'STR#' ("") • All 'STR#'s with no name 'STR#' (128,"") • 'STR# 128, but only if it is unnamed 'STR#' (-32768:-1,"Errors") • All 'STR#'s with negative IDs and named "Errors" A resource <rangelist> is a comma-separated list of 0 or more resource <range>s. If the list is empty, this is usually taken to mean all resources in the file in question. An example of a single legal resource <rangelist> with 8 resource ranges in it might be: 'STR#', 'TEXT', 'STR ' 128:400, 'AUTO' 128, 'SIZE' (-1:0), 'XCMD' ("LegalFoo"), 'TMPL' (0:32767), 'FLTR' (0:32767); Adding copies of resources from other files --------------------------------------- include <filepathname> [ <inputrangelist> ] [ except <skiprangelist> ] ; This opens a given file of resources and reads into the working file all resources in <filepathname> that belong to any range in <inputrangelist> but which do not belong to any range in <skiprangelist>. The “except” clause is optional, and for compatibility with Rez you can use “not” in place of “except”. Under System 7, if <filepathname> is an alias file, then Resorcerer will resolve the alias and open the eventual target file for inclusion. It only does this if the “Resolve alias files” setting is in effect, as shown by the popup in the Open File... dialog. Note: Rez/SARez may not support an <inputrangelist> or <skiprangelist>, only an <inputrange> and <skiprange>. It may not support an <inputrangelist> at all when the “not” keyword is added. The “except” keyword keeps resources falling into its <skiprangelist> from even being loaded, so it is useful, for instance, when you need to exclude a very large resource for which there is not enough memory. Using the “delete” keyword, described below, usually requires resource data to be already loaded into the working file. It is currently not illegal to include resources ID’s that duplicate already included resources. However, when the script ends the working file is checked in the same manner as all newly opened resource files are, and any duplicates will be reported to you. Examples of including resources with various types of ranges might be: include "Original Preferences.rsrc" ; which adds all resources from the file “Original Preferences.rsrc” to the working file. include "MasterTemplates.rsrc" 'TMPL', 'FLTR' except 'TMPL' ("SYM#'), 'FLTR' ("C SYM#"), 'TMPL' ("") ; adds all ‘TMPL’ and all ‘FLTR’ resources from the file “MasterTemplates.rsrc” except any ‘TMPL’ named “SYM#”, any ‘FLTR’ named “C SYM#”, and all ‘TMPL’s with empty names. include "Sound Library alias" except 'snd ' 777, 'snd ' 1000:2000 ; adds all resources in the file “Sound Library” to which “Sound Library alias” points, except ‘snd ’ 777 and all sounds with resource IDs between 1000 and 2000, inclusive. The <inputrangelist> in this case is the empty list, which is taken to mean all resources in the file. read <resource> [ from ] <filepathname> [ <numrange> ] [ ; ] This statement lets you read a given file’s data fork, or any part of the data fork, as a single resource. This is useful, for instance, when you want to create large ‘TEXT’ resources for which a better text processor program exists than Resorcerer’s TextEdit-based Text Editor. The ability to specify the range of bytes in the data fork to read lets you pull in, for example, ‘PICT’ data files as resources of type ‘PICT’, since the data in a ‘PICT’ file contains a 512 byte header that the resource won’t have. When reading partial data, <numrange> can be either a single byte offset, in which case all data from that byte to the end of the file is read, or it can be a colon-separated pair of numbers, the first of which is the offset and the second the length of data in bytes to read. Under System 7, if <filepathname> is an alias file, then Resorcerer will resolve the alias and open the target file for inclusion. It only does this if the “Resolve alias files” setting is in effect, as shown by the popup in the Open File... dialog. The optional “from” preposition is included for readability, so to speak, and is not Rez/SARez compatible. The ability to read partial data forks may not be possible in Rez/SARez either. Examples of legal data fork read statements might be: read 'TEXT' (128, "About Box", purgeable) "About Box Text"; reads all the text in the file "About Box Text" into a new ‘TEXT’ 128 resource with the given name and attributes. read ‘PICT’ 128 from "::Images:MacPaint Idea" 512 ; creates a new ‘PICT’ 128 with all data except the first 512 bytes of “MacPaint Ideas” in it. read 'icl8' 7 from "Icons.data" 0x1000:$400; reads 1024 ($400) bytes, starting at offset 0x1000 from the data in file “Icons.data” and places them in a new ‘icl8’ resource with resource ID 7. Deleting Resources from the Work File ---------------------------------- delete <rangelist> [ except <skiprangelist> ] ; This deletes all resources in the current working file that are included in the given <rangelist>, but not included in the given <skiprangelist>. The “except” clause is optional. If the <rangelist> is empty and there is no except clause, then all resources in the current workfile are cleared. Note: Rez/SARez may not support the deletion of either the empty <rangelist> or anything other than a single <range>, and may not support the “except” (or “not”) clause either Examples of legal delete statements: delete ; deletes all resources in the current in-memory working file. delete 'DLOG', 'DITL' 200:299, 'ictb' 200:299, 'dctb'; clears out all ‘DLOG’ and ‘dctb’ resources, and all ‘DITL’ and ‘ictb’ resources with IDs in the range 200 to 299, inclusive. Delete 'DLOG' 128 ; deletes ‘DLOG’ 128 but does not delete anything else, such as ‘DITL’ 128. Note again that upper/lower case in the keyword makes no difference. Delete 'DLOG' except 'DLOG' 128:140 ; deletes all 'DLOG's except for 'DLOG's 128 through 140, inclusive. No other related resources are deleted. delete 'MENU' ("File"), 'MENU'("Edit"); deletes all menus with resource name “File” or “Edit” (presumably there will be only 1 of each). Remember that it is much better to exclude a resource from being included using the “include ... except ...” statement than it is to include it and then delete it, since in the former case, no memory is required to load the resource data in the first place. The “delete” statement will be more useful when opening and editing existing files by script, which is not yet supported. Changing Resource Information ---------------------------- Currently, the Rez-style “change” instruction, with its somewhat useful but yucchy $$Type, $$Name, etc. string variables is unimplemented. Changing Resource Names ----------------------- For changing resource names, however, a non-Rez-compatible statement is available that lets you rename resource names from any range of resources, excluding another range: rename <rangelist> [ except <skiprangelist> ] [ to ] <namestring>; changes the resource names of all resources in <rangelist> that are not also included in <skiprangelist>. <rangelist> can be empty, which is taken to be all resources in the current working file. The name of each affected resource is changed to <namestring>. The most common use for this is to strip the names from any or all resources in a file. Stripping names (we like to call it “name-dropping”) is often applied before writing out the working file as resources for an application about to be shipped. Doing so can save some disk space, and makes it less pleasant for others to muck about in your application’s resources with their favorite resource editor than it otherwise would be. Of course, you should only strip resource names that are there solely to make editing them easier; names that your application depends on to differentiate among resources of the same type should not be stripped (of their individuality and dignity, no less!). Another use of the rename command is to rename all the ‘CODE’ segments in a built application to something reasonable. Especially for THINK C applications, where the ‘CODE’ resources are created unnamed. Named code resources make MacsBug or other debugger output somewhat more understandable during Heap Dumps. Once the script is written, you can run it easily after each application build to re-install your favorite names. The ability of Resorcerer to rename a resource (or make any other changes) is not affected by any resProtected bit that might be set for the resource (this attribute is basically worthless anyway, as evidenced by the fact that Resorcerer does nothing special to accomplish the overriding of the bit’s properties - just standard documented Resource Manager calls). Examples of legal namedropping: rename to ""; removes the names from every resource in the current working file. Rename 'DLOG', 'ALRT','DITL','STR#'; strips the names from every ‘DLOG’, ‘ALRT’, ‘DITL’, and ‘STR#’ in the current working file. Remember that the interpreter ignores case except in literals and strings, which is why there is no difference between “rename” and “Rename” in the above. rename except 'TMPL', 'SHOW', 'FLTR', 'MPTR' 128, 'TYP#' table1ID:table4ID ; removes the names of all resources in the working file except ‘TMPL’s, ‘SHOW’s, ‘FLTR’s, ‘MPTR’ 128 only, and all ‘TYP#’s with IDs in the given symbolic range. (This statement is taken almost verbatim from Resorcerer’s own “Resorcerer.π.rc” script.) You don’t want to remove the names of certain resource types, such as ‘TMPL’s in Resorcerer, or ‘XCMD’s in HyperCard stacks, because their names contain information that the application depends on. rename 'CODE' 0 to "Jump Table"; rename 'CODE' 1 to "SetUpA5"; rename 'CODE' 2 to "Main"; rename 'CODE' 3 to "Library routines"; ... might be what a possible script would look like for re-installing ‘CODE’ resource names after a new THINK C build has created unnamed ‘CODE’ resources. Changing resource attributes -------------------------- change attributes [of] <rangelist> [ except <skiprangelist> ] [ to ] <attributelist> ; lets you set attribute bits in all resources in <rangelist> except any in <skiprangelist> using the attributes specified in the given <attributelist>. <attributelist> should be a list of 0 or more comma-separated attribute names. For each resource in the range being changed, attribute bits are only changed if there is explicit mention of one of the attribute names in this list. If the attribute name is for a set bit (sysheap, purgeable, locked, protected, or preload), then that attribute is or’ed into the resource’s current attribute word; if the attribute name is for a clear bit (appheap, nonpurgeable, unlocked, unprotected, nonpreload), then the negative of the attribute is and’ed into the resource attributes. This means that if you want to guarantee that all attributes of a resource are exactly what you want, you have to explicitly declare how you want each bit set. And since at this time there is no expression evaluation capability, you cannot set attributes numerically. For example, change attributes to purgeable; ensures that every resource in the working file has its purgeable bit set, whereas change attributes to nonpurgeable; ensures that every resource in the working file has its purgeable bit clear. change attributes; change attributes of 'STR ', 'STR#', 'TEXT', 'styl' to; both do nothing. change attributes of 'DLOG', 'ALRT', 'DITL' except 'ALRT' 128, 'DITL' 128 to purgeable, nonpreload; change attributes of 'ALRT' 128, 'DITL' 128 to nonpurgeable, preload; ensures that every ‘DLOG’, ‘ALRT’, and ‘DITL’ is purgeable except for one particular alert and its item list, which should always be loaded and available. Any of the other attributes are left unaffected. change attributes of 'MENU' 1:30 to nonpurgeable, preload, unlocked, appheap, nonprotected sets all menus with IDs between 1 and 30, inclusive, to have the exact attributes specified. change attributes of 'CODE' 2:48 to resProtected+resLocked is not supported at this time. Changing resource IDs -------------------- change ID [of] <rangelist> [ except <skiprangelist> ] [ to ] <resID> ; lets you renumber in all resources in <rangelist> except any in <skiprangelist> to the given resource ID number. It is an error for there to be more than one resource in <rangelist> having the same type. This command does not renumber ranges of resources to sequences of resource IDs starting at <resID>. Nor does it renumber any related or owned resources.